极限编程(eXtreme Programming)是近几年才时兴起的开发模型，主要是针对中小型开发团队在开发时间要求紧、需求不稳定的中小项目（大多数软件项目都是这个情况）时使用。

极限编程打破了传统软件工程的框架，非常新巧。如：

整个开发过程中文档很少，大量使用“卡片（如CRC卡片）”来描述开发计划和内容
没有真正意义上的软件功能规格说明书，取而代之的是一系列可测试的用例
没有独立的设计和测试阶段，它们总是在迭代中增量反复进行
设计：尽可能小和简单；一般没有代码复审（code review)，大家共同拥有代码
而它的最显著的一个外在特征是它常使用“成对开发”

极限编程XP的特点可以用“快、小、灵”来概括，极限编程和传统瀑布模型（自顶向下）的区别在于它使用迭代增量（设计->代码->测试->设计->代码…)的方式。

第一部分：问题

最基本的问题：风险

常见的风险以及XP如何化解？

进度延迟——XP发行周期较短；一个发行周期内，要求对客户提出的功能进行一到四周的迭代，优先实现优先级较高的功能
项目取消——XP让客户选择具有最大业务意义的最小版本，从而在投入生产前减少发生错误的几率
系统恶化——XP创建并维护一整套测试程序，每次发生变化后都要重新运行测试程序以确保质量
缺陷率高——XP测试时，既遵从程序员按逐条功能编写测试程序的观点，又遵从客户按逐个程序特性编写测试程序的观点
业务误解——XP要求客户成为整个团队的一部分
业务变更——XP缩短了版本周期，因此每个版本的开发过程中的变化就少
错误过多——XP强调只专注于具有最高优先级的任务
人员调整——XP要求程序员承担估算和完成自己工作的责任，并将实际花费时间进行反馈，以改进他们的估算

开发过程

XP的完整开发过程：

结对编程
测试驱动开发
结对开发不仅要运行测试用例，还要改进系统设计
开发之后接着进行集成，以及集成测试

极限编程的基本出发是认为成对开发的效率在一定条件下要高于两个人独立开发的和。在很多项目中，这种做法的有效性已经被证实。

软件开发的经济学

我们需要通过减少开销，更快地获得收入，并增加项目的可能生产周期，从而使我们的软件开发在经济上更具价值。但最重要的是，我们需要增加商业决策的选项。

我们可以制定一个最大化项目经济价值的战略。

减少开销，但是这很困难
赚取更多，但这对一个优秀的营销组织可能更加容易
以后花钱并且赚得更快，所以我们支付的利息更少，我们花的钱也更多，我们赚的钱也更多。
增加项目存货的可能性，所以我们更有可能在项目后期获得巨大回报。

四大变量

软件开发过程中的四大变量

成本——钱多一点可以促进工作顺利进行，但短时间内投入太多金钱会产生更多无法解决的问题
时间——更长的交付时间有助于提高质量和扩大范围
质量——有意识的牺牲质量，可能在短时间内获利，但是未来耗费的成本是巨大的
范围——更小的范围有助于提高质量

专注于范围
许多人知道成本，质量和时间作为控制变量，但不承认第四种。对于软件开发来说，范围是需要注意的最重要的变量。程序员和商业人士对开发中的软件有什么价值都没有模糊的概念。项目管理中最强有力的决定之一就是消除范围。

关于范围的一个很棒的事情是它是一个变化很大的变量。几十年来，程序员一直在抱怨：“客户不能告诉我们他们想要什么，当我们给他们他们想说的话时，他们不喜欢它。” 这是软件开发的绝对真理。起初，这些要求从来不明确。顾客永远无法确切地告诉你他们想要什么。

通过不尝试做太多，可以保持按时生产所需质量的能力。

如果我们根据这个模型创建了一个开发规则，我们将确定一个软件的日期，质量和成本。我们会看前三个变量所隐含的范围。然后，随着发展的进展，我们会不断调整范围以符合我们发现它们的条件。

变化的成本

软件工程的普遍假设之一是改变程序的成本随着时间呈指数级增长。

以下几个因素，可以使得我们的代码即使经过长时间开发也可以很容易修改

简单的设计
自动化测试
不断改进设计

学会开车

我们需要通过一些小的调整来控制软件的开发，而不是做一些大的调整，就像驾驶汽车一样。这意味着我们需要反馈意见来了解我们何时休假，我们需要很多机会进行更正，而且我们必须能够以合理的成本进行更正。

软件中的一切都在变化。需求改变，设计更改，技术变化，团队改变，团队成员改变。只有变化才是永远不变的。

四个价值观

XP的四大价值观

沟通——项目问题总是可以追溯到有人不跟其他人谈论重要的事情。XP旨在在团队成员之间保持良好的沟通。
简化——简单和沟通有着美妙的互相支持的关系。你越多沟通，更清晰，你可以看到究竟需要做什么和更多的信心你有什么真的不需要做。你的系统越简单，你就越少沟通，这会导致更完整的沟通，尤其是如果可以的话简化系统足以减少程序员。
反馈——系统绝对是无价的。乐观是编程的职业危害，反馈是对这一危害的治疗。
勇气——要勇敢地修正体系结构中的错误，勇敢地抛弃原有的代码。

基本原则

XP的基本原则

快速反馈——行动与反馈之间的间隔对学习至关重要。
假设简单性——把每个问题都看做可以用近乎荒谬的简单方法来解决。
递增更改——每次修改一点点，即使采用XP也必须采用小步骤。
拥抱变化——最佳的策略就是在实践中运用最多的策略，优先解决最重要的问题。
优质工作——出色完成工作是项目最终成功的保证。

回到基础

开发中的四项基本活动

编码——编码是了解最佳结构的方式，同时也能提供清晰简洁的沟通。
测试——测试既是资源也是责任。
倾听——如果准备提问，那么最好准备好倾听答案。
设计——良好的设计可以可以降低系统变更的成本，提高系统的可扩展性

第二部分：解决方案

快速概述

商业考虑和技术考虑都不应该是最重要的。软件发展始终是可能和理想之间的一个不断发展的对话。

商务人士需要决定：

范围——该系统必须解决多少问题才有价值生产？商人有能力了解有多少钱是不够的，多少太多了。
优先级——如果您最初只能拥有A或B，您想要哪一个？生意人能够确定这一点，远比程序员更重要。
发布的组成——业务之前需要完成多少或多少工作用软件比没用它好？程序员对这个问题的直觉可能是疯狂的错误。
发布日期——什么是重要的日期，软件的存在（或一些软件）会产生很大的不同？

技术人员决定：

估计——多久会采取功能来实现？
后果——有战略业务决定，应该只在什么时候做出。了解技术后果。数据库的选择就是一个很好的例子。与创业公司相比，企业可能更愿意与一家大公司合作，生产力可能会使额外的风险或不适感到值得。
过程——如何将工作和团队组织？团队需要适应文化。
详细调度——程序员需要自由安排最高风险的发展部分，以减少项目的总体风险。在这种限制之下，他们仍然倾向于改变业务优先级。

每次发布应该尽可能小，包含最有价值的业务要求。版本必须作为一个整体来理解 - 也就是说，你无法实现一半功能并发布它。

在任何时间，软件的正确设计都是这样的：

运行所有测试。
没有重复的逻辑。对像平行类层次结构这样的隐藏重复要小心。
说明对程序员重要的每一个意图。
尽可能少的类和方法。

任何没有自动化测试的程序功能都不存在。

在XP中，每个人都对整个系统负责。不是每个人都知道每个部分。同样，虽然每个人都知道每个部分的一些东西。如果一对正在工作，他们看到改进代码的机会，他们继续前进，如果让他们的生活更轻松，那就改进它。

真正的客户必须与团队坐在一起，可以回答问题，解决纠纷并进行设置小规模优先事项。

编码标准应该尽可能少的工作，符合一次和唯一。标准应该强调沟通。最后，标准必须由整个团队自愿采用

如何工作

任何一种做法都不可能很好的单独进行。他们要与其他做法一起运用，以保持平衡。

管理策略

管理方面的困境：一方面，你希望经理能够做到这一点决定。没有通信开销，因为只有一个人。有一个人对上级管理层负责。有一个人有远见。没有其他人需要了解它，因为所有的决定都来自一个人。

另一方面，相反的策略是行不通的，不能让每个人都去做决定。

基本的XP管理工作是度量标准。制作大的可视表，对任务总量进行度量。

理想的教练是一个很好的沟通者。

教练的工作职责：

作为新手程序员的开发伙伴。
参与长期重构目标，并鼓励小规模重构来解决部分问题。
帮助具有个人特殊擅长领域的程序员。
向上层管理人员解释开发过程。

跟踪是XP中管理的另一个主要组成部分。跟踪器的工作是收集当前正在跟踪的任何指标并进行确信团队知道实际测量的是什么。运行计划是跟踪器的一部分。

管理人员的干预，可能是调整团队人员结构，甚至也可能是直接终止项目。

设施战略

我们将为我们的团队创建一个开放的工作空间，周围有小型私人空间外围和中间的一个公共编程区域。如果你没有合理的工作场所，你的项目将不会成功。

分裂商业和技术

战略的关键之一是让技术人员关注技术问题，商业人员关注业务问题。

商业人士应该：

发布的范围和时间
建议功能的相对优先级
建议功能的明确范围

技术人员应该：

估计实现各种功能所需的时间
估计各种技术方案的后果
一个适合他们个性、商业环境和发展过程的公司文化

规划策略

我们会迅速制定一个总体计划，然后再进一步细化更短更短的时间范围——年，月，周，天。我们会做的计划迅速且便宜，所以当我们必须改变它时，会有小的惯性。

计划的三个阶段

探索——找出系统能做出什么新东西
承诺——决定接下来要追求的所有可能要求的哪一部分
转向——为现实的开发做出指导计划

发展战略

与管理战略不同，发展战略是一个彻底的相反的观点。从传统的观点来看，我们将为今天的问题精心制定解决方案。今天，相信明天我们将能够解决明天的问题。

发展战略始于迭代计划。持续集成减少发展冲突并为发展事件创造自然结局。集体所有权鼓励整个团队改善整个系统。最后，结对编程将整个过程联系在一起。

持续集成显著降低了项目风险。

代码集体所有权的影响之一就是复杂代码不会存在很长时间。集体所有权倾向于防止复杂代码很早进入系统。集体所有权也倾向于围绕团队传播系统知识。

设计策略

我们将不断完善系统的设计，从一个非常简单的设计开始，删除任何无用的灵活性。

最佳设计的定义是运行所有测试用例的最简单的设计。

测试策略

在编码之前编写测试，一次又一次地运行测试。我们将永远保留这些测试，并经常一起运行它们。

XP中编写的测试是独立且自动的。

单元测试和功能测试是产品测试的核心。除了单元测试，还有其他同样很重要的测试：并行测试、压力测试、灵活测试。

第三部分：实施XP

采用XP

一次采用一种XP方法，解决团队遇到的最紧迫的问题。当当前问题不再是最紧迫的问题，继续解决下一个最紧迫的问题。

改进XP

如何在现有团队中使用已经投入生产的软件来使用XP？必须在以下方面修改采用策略：

测试——试图返回并为所有现有代码编写测试是很有诱惑力的，但不建议这么做，测试应该是按需编写。
设计——一次只重构一点，在添加新功能时做好重构准备。
计划——切换到XP计划的最大挑战（和机会）是教会客户他们可以从团队中获得多少。
管理——管理向XP转变的最困难的方面之一是决定一个团队成员不再需要工作。
开发——重视结对编程，并准备随时丢弃已经开发出的代码。

理想XP项目的生命周期

XP项目的生命周期：

探索——探索完成这个项目所需要的开发技能。
计划——让客户和程序员自信地达成一致的一个最小，最有价值的故事集合的日期。
第一版本迭代——承诺时间表被分成一到四周的迭代次数。每次迭代都会产生一个为该迭代计划的每个故事设置功能测试用例集。
生产——在开发过程中，会放慢软件开发的速度，评估系统风险是否变得更加重要。
维护——维护实际上是XP项目的正常状态。在生产新的功能的同时，维护系统已有功能正常稳定运行。
死亡——死亡的最好理由：客户对系统满意并且无法想到任何事情他们希望在可预见的未来增加。

任务角色

程序员——XP的核心
顾客——极限编程基本二元性的另一半
测试人员——编写测试用例，负责测试系统
跟踪者——做出好的估计，手机各种反馈
教练——为整个过程负责
顾问——帮助解决某个领域深入的技术知识问题
大老板——提供团队勇气、信心以及放权

20-80原则

XP的全部价值在所有的实践到位之后才会实现。很多实践可以采取零碎的做法，但是它们的影响会在成倍增加在一起。

软件程序员习惯于处理20-80规则：80％的好处来自于此20％的工作。

什么让XP变得艰难

主要是情绪，特别是恐惧，使XP变得困难。

XP的细节很简单，但是很难执行。

什么时候不应该使用XP

大团队，不信任的客户，技术不支持优美的变化。这些情况下，不应该再继续使用XP。

工作中的XP

注意使用适用于XP的合同

结论

XP反映了恐惧的事情：

没有意义的开销
因为没有做好充分的技术准备而被取消的项目
糟糕的商业决策
由业务人员作出技术决策
职业生涯的结束
项目结果不令人满意

XP也反映了不害怕的事情：

编码
拥抱变化
不知道未来的发展
依赖其他人
变化运行系统的分析与设计
编写测试